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© Multiple graphical user interface on a single display. 



^ © The invention includes at least two interconnected computer systems, each having a different operating 
<^ system running thereon. A client system may be running the OS/2 operating system and a second, server 

computer the AIX system. The server system that allocates display screen space for application windows 
|H running on the server system and supports window management. Further, the window management places GUI 

borders around the application window which allow a user to interact with the client application running therein. 

The functions in these GUI borders include a menu bar, scroll bar, sizing features, pull down windows, and the 
^ like. The client application is mapped into a form which enables the application commands to be recognized by 
lyfg a library of functional calls associated with the server system. The server system, displays the client application 
_ in the designated window along with the server GUI; 
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The present invention generally relates to the display of an application on the screen of a remote 
computer system. More particularly, a program application that runs on a first operating system is capable 
of being displayed on the screen of a computer system using a second different operating system such that 
the Graphical User Interface (GUI) of the second operating system is used to present the program 
application of the first operating system. 

Currently it is known for an operating system window manager to allocate a portion of a display screen 
that can be used by an operating system. In particular, US 4,937,036, 4,937,507 and 4,920,481 describe 
. systems wherein a portion of the display screen is allocated for use by a processor which emulates another 
processor in this window. This window will include the user interface for the emulated operating system. 

" US 4,961,133 discusses a system for providing portability of program applications across different 
hardware and operating system environments. The transportable code is compiled and linked to create 
code executable by another operating system. US 4,855,936 is an application program interface that 
handles full screen input/output (I/O) display operations. The application program is required to determine 
display characteristics prior to performing full screen I/O operations and provide a buffer as output is to be 
performed. The application programming interface provides a means for allowing an application program- 
mer to write an application without being concerned with the low level detail of full screen I/O operations. 
That is, the application is architecture independent with respect to the full screen I/O operations. Japanese 
patent JP 58-31438 is a system that converts messages into specific display format suitable for centralized 
monitoring and control. A protocol converting portion transforms a message into a specific format, as 
required. The central monitoring system established an interface for transmitting/receiving the protocol. 

It can be seen that the related art merely allows for a host system to allocate a specific portion of its 
display to a client operating system, which is either emulated from the host processor, or remotely 
connected. However, each of the described references requires a client Operating System window. Further, 
if the client operating system supports windowed applications, such application windows are confined to the 
client OS window. None of the described references can display a client OS application window directly on 
the host OS window without the need for a client OS window. A need exists for a system wherein multiple 
application windows from multiple client operating systems can be run as peers with hose application 
windows in a host operating system window. However, none of the described references show a first 
system, which uses its own window manager to display the first operating system GUI in a window, running 
a program application written for an entirely different operating system, concurrently in the same window 
with the first operating system GUI. Thus, it can be seen that a need exists for a system wherein multiple 
graphical user interfaces can be run concurrently in a single window. 

Is desirable to have the ability to use the GUI that is most familiar to a user, even when running a 
application program that operates in conjunction with an unfamiliar operating system, or GUI. For example, 
an AIX user will appreciate being able to run an application written for OS/2 within a window in conjunction 
with the AIX graphical user interface. In this manner a distributed system is created wherein, applications 
running on a first system are used remotely. 

Broadly, the present invention includes at least two interconnected computer systems, each having a 
different operating system running thereon. For example, a first system may be running the OS/2 system 
and a second computer the AIX system. The X Window System (X) is a display environment, or graphical 
user interface that is available from MIT (X Window System is a trademark of the Massachusetts Institute of 
Technology) and runs on the operating systems, such as the UNIX system, AIX operating system, and other 
systems based on the UNIX OS. This GUi includes a server (X server) that allocates display screen space 
for applications running on the AIX system. Further, the window manager places GUI borders in the window 
which allow a user to interact with the application running therein. The functions in these GUI borders 
include a menu bar, title bar, scroll bar, sizing features, pull down windows, and the like. The present 
invention allows a non-AlX application (such as an OS/2 application), a non X Window application, or the 
like, to run within the window allocated by the AIX window manager and in conjunction with the AIX (X11) 
GUI border contained therein. 

First, the non-AlX application calls are mapped into an X11 form which enables the application 
commands to be recognized by the X library of functional calls. The operating system, for which this 
application was written, e.g. OS/2, must be compatible with the X library (X lib). The operating system then 
sends the translated OS/2 application instructions to, for example, the AIX operating system through the 
TCP/IP communications protocol. The X11 server, working in conjunction with the X window manager 
displays the OS/2 application in the designated window along with the AIX GUI. In this manner the output of 
an OS/2 application will be displayed in conjunction with the AIX graphical user interface. Further, the 
process is reversed and input from the user , to the AIX GUI, are mapped into OS/2 application calls such 
that the OS/2 application can be manipulated by input to the AIX GUI. 
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These and other objects are accomplished by the invention as claimed. 

Figure 1 is a schematic representation of a typical data processing system with which the present 
invention can be utilized; 

Figure 2 is a block diagram showing the specific components of a system using the present invention 
and their relationship with one another; 

Figure 3 is a display screen of a computer system illustrating another embodiment of the present 
invention wherein a remote application is running in the same window with the GUI of a system using a 
different operating system; 

Figure 4 is a display screen of a computer system illustrating a first embodiment of the present invention 
wherein a remote application and its GUI are running on a system with a different operating system; 
Figures 5 A-C are flowcharts illustrating the mapping function of the present invention which allows a 
program application to be interactively running in a window of a display on a computer system with a 
different operating system wherein multiple GUI's are present. 

Referring to Figure 1 , a typical data processing system is shown which may be used in conjunction with 
the present invention. A central processing unit (CPU) 10, such as one of the Intel X86 processors or an 
IBM reduced instruction set computing (RISC) processors, is provided and interconnected to the various 
other components by system bus 12. Read only memory (ROM) 16 is connected to CPU 10 via bus 12 and 
includes the basic input/output system (BIOS) that controls the basic computer functions. Random access 
memory (RAM) 14, I/O adapter 18 and communications adapter 34 are also interconnected to system bus 
12. I/O adapter 18 may be a small computer system interface (SCSI) adapter that communicates with a disk ' 
storage device 20. Communications adapter 34 interconnects bus 12 with an outside network enabling the 
data processing system to communicate with other such systems. Input/Output devices are also connected 
to system bus 12 via user interface adapter 22 and display adapter 36. Keyboard 24, track ball 32, mouse 
26 and speaker 28 are all interconnected to bus 12 via user interface adapter 22. Display monitor 38 is 
connected to system bus 12 by display adapter 36. In this manner, a user is capable of unpitying to the 
system through the keyboard 24, track ball 32 or mouse 26 and receiving output from the system via 
speaker 28 and display 38. Additionally, the operating system such as DOS, AIX or the OS/2 system (AIX 
and OS/2 are Trademarks of IBM Corporation) is used to coordinate the functions of the various 
components shown in Figure 1. The computer system shown in Figure 1 is an example of the type of 
. systems that are capable of utilizing the present invention and can be used as the. host or remote system. 

Figure 2 is a block diagram showing the various components of an interconnected system utilizing the 
present invention. A client system is generally noted by reference numeral 1. A client program application 3 
is shown, which is a program written specifically for a particular operating system. In this case the client 
application, is written for the OS/2 operating system. Further, the Presentation Manager (PM) 11 is provided 
which is a programming interface used in conjunction with the OS/2 system. The purpose of PM is to 
provide a consistent application program interface for application written to OS/2. Specifically, PM provides 
Gpi and Win API support for the OS/2 applications. That is, PM provides all of the graphics support (Gpi) 
and window management (WIN API) for the program applications. 

In order for the present invention to function, the calls from the PM 11 must be mapped into a form that 
is recognizable by the operating system running on the interconnected system. For example, the X1 1 
graphical user interface is commonly used in conjunction with systems based on the UNIX operating 
system (UNIX is a registered trademark licensed exclusively by X/Open Company Ltd.), such as the AIX 
system. Thus, a mapping mechanism 5 is provided which will transform the application calls into a form that 
is recognizable by the interconnected operating system. This mapping function will be described in more 
detail in conjunction with Figures 5A through 5C, described below. 

Generally, window systems (i.e. GUI) are tied to a specific operating system, e.g. PM and OS/2. 
Therefore, the term operating system as used herein will include the windowing system. It should be noted 
that the X Windows System is designed top operate across multiple operating system platforms. As 
described herein, the operating system on which X Windows is running will be considered as including the 
X Window System. The X Windows interface includes a, library of function calls, known as the X library. 
This library includes commands that will control various display functions, such as input/output control of 
the display, keyboard, mouse, and the like. This library is essentially a collection of routines that can be 
used to create an X client program application. Thus, due to the mapping of the PM calls into X lib calls, 
the OS/2 application 3 essentially becomes an X client application. Operating system. 9 is shown as the 
OS/2 system from IBM Corp. and provides all of the low level control and data management functions 
required to implement application programs on specific hardware platforms, such as the PS/2 computer 
system, commercially available from IBM Corporation (PS/2 is a trademark of IBM Corp.). The operating 
system 9 then communicates with a remote operating system 101 (e.g. AIX) by way of a communications 
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protocol, such as TCP/IP, or the like. In this manner the two different, incompatible operating systems, e.g. 
OS/2 and AIX can communicate with one another. 

The X server component 103 is running on the AIX system and provides screen management facilities 
for display 107. More particularly, the X server is a graphics driver that controls the system, it handles 
requests from an X client application to created windows, draw lines, circles, text, and the like on the 
computer system display screen. Further, the X server will handle keyboard and mouse input from the 
computer system and relays this information back to the X client. A window manager 105 is also part of the 
X Windows interface and is used to allocate screen resources between various program applications, as 
well as, operating system functions that require information to be displayed. The window manager is a 
special X client that is run (one for. each X server) in order to supervise the control of windows created on 
the display. The window manager creates the "look and feel" of the user interface. Further, the window 
manager is responsible for placing any border around the window, such as a title bar, control buttons to 
maximize or minimize the window, scroti buttons, system menu, or the like. The window manager also 
handles user input requiring movement or resizing of the window. In a preferred embodiment of the present 
invention, the Motif window manager from the Open Software Foundation (OSF) is contemplated for use as 
window manager 105. It should be noted that those of skill in this art will be familiar with the operation of 
the X Window System components. Therefore, the function of these components will not be further 
discussed. 

Figure 3 is a screen on display 107 showing a typical X Windows display workplace wherein various 
AIX system program applications are running. For example a clock program 109 is shown along with an AIX 
application running in an X Window 113. The AIX application may be a word processing/desktop publishing 
application, such as Interleaf, AIX Interface Composer, or the like. Of course, many other program 
applications are capable of being run in window 113. A graphical user interface 111 is shown around the 
periphery of window 113. This is part of the X GUI and includes I/O features such as. software buttons, a 
scroll bar, pull down menus, a title bar 119, icons 121, and the like. Another window 117 is shown on 
display 107 which is an OS/2 system program application, such as Lotus 1-2-3, Excel, Clock, or the like 
running therein. Additionally, an X system GUI border 115 is present around the periphery of window 117. 
GUI 115 includes all of the I/O components normally found in an X border, which includes the scroll bar, 
icons, and the like, previously mentioned. In this manner, a user is capable of running a program application 
written for a first specific operating system (e.g. OS/2) on a platform having a second different operating 
system (e.g. AIX) such that the program application written for the first operating system responds to the 
user inputs to GUI associated with the second operating system. Further, the program application will 
provide output to the user in accordance with the GUI from the second operating system. For example, the 
program application may provide. different titles to the window manager 105 for display on the title bar, and 
the scroll bar on the GUI border will change as the user scrolls through a document in a word processing 
application. Thus, the program application must provide output to the GUI in order for it to display the 
proper position of the scroll bar. It can be seen that not only does the present invention provide a system 
that allows a user to run program applications written for a different operating system, but also allows the 
user to interact with the application through a graphical user interface, based on -the operating system 
resident on their system. Thus, a user can run applications written for different systems, and still be able to 
interact with these new applications through a familiar graphical user interface. 

Figure 4 is a screen of display 107 illustrating another embodiment of the present invention. More 
particularly, the same AIX applications 109, 111, 113 are shown running on the display, along with a 
Distributed PM application 117 running in a window having DPM border 115. In this case, the DPM GUI is 
displayed on top of the AIX border, such that the user sees only the DPM GUI. Additionally, it is possible to 
"shadow" the AIX border with the DPM border such that both are visible. In most cases both sets of 
functions will work and the user can use the GUI which is most familiar. 

Referring to the flow charts of Figures 5A-5C, the operation of the present invention will now be 
described. It should be noted that Figures 5A-5C are representative of the operations that the present 
invention will perform in order to display a client application in a window of a host system, there are 
innumerable combinations of PM outputs that must be mapped to X lib calls. Thus, Figures 5A-5C show the 
basic functions of line drawing, curve drawing and text mapping. Those skilled in the art will understand 
how to apply, these basic mapping operations to other functions output from the client application. 

At step 1 the remote, or client application is initiated. One way is for the host, or server system user to 
input a startup.cmd and syslogin.cmd commands. This method will resemble remote startup using the RSH 
daemon on TCP/IP. For example, the AIX user will issue the command: 
rsh $NODE n start/dpmx = $DISPLAY my_app" 

This command will cause the DPM daemon on remote node $NODE to prompt for a username and 
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password. If the user name and password are valid the process is then started. At step 2, the application 
calls the Winlnitialize command which checks for the Distributed PM environment. If the DPM exists, a 
specific dynamic linked library is called that will build a table of subroutine addresses that will convert the 
calls to X library recognizable commands. This dynamic linked library (DLL) is provided in the PM interface 
application. Further, the calls from the application to the WIN and Gpi APIs in the PM interface are captured 
and redirected to the X library. 

There are two types of window GUI's that can be used, as illustrated by Figures 3 and 4. Figure 3 
shows a system where there is not subclassing. This means that DPM. will make no change to the default 
setting and the local window manager will be in control. This is the preferred embodiment and will include 
an X Window System having a GUI border that includes the title bar, scroll bar, software buttons, window 
sizing icons, and the like associated with a standard X GUI. A subclassed GUI means that the DPM GUI will 
be displayed either in conjunction with the X GUI or written on top of the X GUI such that only the DPM 
border is visible. 

At step 3, the PM to X mapping layer 5 is used to translate the PM calls to X recognizable commands. 
A translate table is used to accomplish this conversion. Several problems had to be overcome in order to 
make this conversion. For example, the X window manager normally, initializes a window and then instructs 
the X client application that it has permission to write to the window. In contrast, the PM interface is used to 
opening a window and then immediately drawing to it. The PM method contemplates local, not networked 
systems. Thus, a conversion had to be made that would cause the PM interface to wait for some period of 
time before drawing to the X window. Further, a mapping relationship was created between the PM and X 
systems $o that the X Window handles could be recognized and manipulated by the application 3 running 
on the remote system. The window manager will also recognize input from the DPM (via the X lib and X 
server) that will allow the titles on the GUI title bar to be changed. For example, if the X GUI title bar 
includes File. Edit, Help and Options, but the DPM program application also includes the title of Tools, then 
the DPM command can be translated and sent to the X window manager in order to make the title bar 
consistent with the program application running on OS/2. 

Subsequent to step 3, the window has been created on the display 107 and it is then determined if the 
distributed PM application needs to draw lines (step 4). If so, the process continues to step 5 where the line 
coordinates are translated by the PM to X mapping means 5. It should be noted that line drawing is a fairly 
straight forward process, i.e. beginning and ending points are identified and the intermediate pixels must be 
painted. In the X system, the initial pixel 0,0 is at the upper right portion of the screen and with PM it is at 
the lower right corner. There- fore, the y coordinates of the pixels must be translated. Once the translation 
is complete, the call is made (step 6) from the PM interface 11 to the X lib 7, which then outputs the 
equivalent X commands that will cause the line to be drawn. The line is then drawn into the window at step 
7, and the operation jumps to step 17. 

If it is determined that there is no line to be drawn at step 4, the operation proceeds to step 8 which 
determines if text is to be written into the window. If so, the DPM text characters are translated by the 
mapping means 5 and input to X lib 7 (step 9). Both PM and X use ASCII characters so this translation is 
relatively simple. However, these two systems do not necessarily use interchangeable fonts. Therefore, at 
step 10, the mapping means compares the PM fonts to the closest predetermined X fonts and outputs the 
command for these X fonts to the X lib. At step 11, the translated text is presented in the displayed in 
window 117 of Figure. 3. Subsequent to step 11 the method proceeds to step 17. If, at step 8 there is no 
text to be drawn, then the method proceeds to step 12 which determines if a curve, such as a spline, is to 
be displayed. If so, the PM interface outputs the beginning and ending points of the curve to the mapping 
means (step 1 3). In many cases, the X lib will not include function that corresponds to the function desired 
by the program application. Curves are one example of this type of function. Therefore, it was determined 
that support needed to be provided for a spline, which is a type of curve. In this case, the PM interface 
provides the coordinates for the endpoints to the mapping means. Further, the PM interface will indicate 
that a spline is to be drawn. Since, there is no equivalent function in the X lib, the mapping means then 
provides this new functionality by calling a subroutine (step 14) which determines which pixels intermediate 
the endpoints must be painted in order to create the spline. This subroutine effectively uses the existing X 
lib functions to describe the shape of the curve to be displayed. Once these pixels are determined, calls are 
made to a standard line draw routine in the X lib 7 for these pixels. The X lib then outputs commands which 
will cause the appropriate pixels to be painted. It can be seen that a virtually unlimited amount of new 
function may have to be supported in the mapping means, in order to support the function that is 
continuously being added to new applications being written. At step 15, the output from the X lib, that 
represents the curve is provided to the X serverso the curve can be drawn in the window (step 16). 
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If at step 12 it was determined that no curves were to be displayed the operation skips to step 22 which 
determines if there are any other application output requests to be processed. If so, step 23 maps the 
output from PM into an X call. Step 24 then makes the call to the X lib and the display is output on the 
window at step 25. If there are no other application output requests, then the process moves directly from 
5 step 22 to step 17. 

At step 17 it is determined if the host system user (AIX) will interact with the remote application (OS/2) 
by entering input. If not, the process continues to step 26. If the application does allow for user interaction, 
at step 18, an identifier is returned to the X server 103. This identifier will be in the form of a number that 
corresponds to keystrokes, or mouse position/click information. At step 19, the mapping means 5 will 

70 translate the number corresponding to the X system input into a letter that is recognizable by the DPM 
system. A translate table is used to make this conversion which takes into account certain predetermined 
conditions. For example, the X system allows for one finger keyboard operation wherein a user can press 
shift and subsequently press, e.g. M H\ and the result will be identical to pressing shift and "H" 
simultaneously. It can be seen that all of the various combinations of keyboard input must be taken into 

rs account when translating user input. Once the translation is completed by the mapping means 5 ( the 
corresponding PM commands are sent to the PM interface 11 and provided to the application 3 as input 
(step 20). Subsequent to step 20, the method proceeds to step 26 which determines if the application 
program has ended. If so, the window is closed at step 21 and the process ends. However, if the program 
has not ended, then the method returns to step 4, and the process (subsequent to the creation of the 

20 window) is repeated. 

The main function of the mapping means 5 is to redirect calls to the PM interface (specifically, to the 
PM WIN and Gpi APIs) to the X lib. As described above, some of the translation is fairly straightforward. If 
an X lib call exists that corresponds to a PM call, then some simple parameter shuffling may be all that is 
required. However, as noted above, for complex graphical functions the mapping means will have to break 
25 down the function and emulate it with multiple calls to the X lib (e.g. spline subroutine). Other PM calls 
require the establishment of data structures to hold local context or provide a mapping from a PM structure 
to an X structure, as in the case of a PM window handle being mapped to an X window handle/display 
combination). 

It should be understood that the above description of various translations are provided as examples and 
30 should not be considered as all of the types of translations that must be performed by the mapping means. 
The present invention allows graphical or windowed program applications run on a first system to be 
displayed and interacted with through a GUI running on a second different operating system. 

As noted above, there are many types of client application functions that must be mapped to the server 
system. These functions include font support, window management, cursor support (e.g. mouse pointer vs. 
35 text cursor), line drawing, curve drawing, text mapping, bitmap conversion, and the like. It has been shown 
that some of these functions are relatively simple (e.g. line drawing and text mapping) while others are 
extremely complicated (e.g. curve drawing). As a representative example of how one of the more complex 
functions can be mapped between the client application and the server window system, the following 
description is provided. 

40 - 
BITMAP FUNCTION MAPPING 

The Bitmap component of DPM is concerned with all functionality related to displaying, modifying, and 
querying bitmaps. Only bitmaps that have been created explicitly (i.e. that have a specific HBITMAP handle) 
45 are ever eligible to reside on the server. Since bitmaps created in other ways either cannot be monitored or 
are transient, there is little performance lost in sending these to the server each time. The server has a 
limited capability for storing bitmaps (pixmaps). If the server cannot store a bitmap, then previous bitmaps 
are removed in a least-recently-used order. Locally, these bitmaps are marked to indicate this fact 

50 
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API DETAILS 
API NAME 
GpiBrtBrtQ 



w 



15 



20 



DESCRIPTION OF CHANGES 



This function moves bit arrays between two presentation spaces, both of which may 
be the same. Alternatively, only one presentation space can be provided. In this 
case, the blitting operation will involve only the manipulation of destination bit data 
and possibly pattern data.The source and destination presentation spaces may or 
may not be associated with a remote window. The action that GpiBitBltO takes 
depends on this. The following description summarizes the four scenarios possible. 

(1) If both source and destination presentation spaces are local, then blitting takes 
place on the local PM machine in the standard way. 

(2) If the destination presentation space is a remote window and the source 
presentation space is associated with a bitmap that is server- potential and is 



25 



30 



35 



40 



45 
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current (up-to-date on the server), then Witting is handled by the server. No 
transportation of the bitmap to the server need take place. If the resident bitmap is 
not current, then the bitmap is updated to the server again, marked as current, and 
5 then copied (at the server) to the destination window. 

(3) If the destination presentation space is a remote window and no 
server-potential bitmap (or no bitmap at all) has been selected into the source 
presentation space, then blitting is performed by copying the bitmap directly to the 
remote window. No storage of the bitmap is performed on the server. 

(4) If both the source and destination presentation spaces are remote windows, 
then blitting takes place on the server directly. Background patterning takes place 

is when certain raster operations are specified. This is taken care of on the server end 

by setting up a "stipple" of the appropriate background pattern into the graphic 
context used during the blitting operation. If the pattern is one of the standard PM 
patterns, then a stipple matching the pattern is created on the server the first time 

20 . 

required, and left permanently on the server. It affects future drawing by being 
selected into a GC used in a drawing command. 

25 

GpiWCBitBltO 

This function operates just as GpiBitBltO does with these differences; 

30 

the source is always a bitmap, and not a presentation space. This means that the 
source always behaves like a memory presentation space with a bitmap associated 
with it. 

35 The destination presentation space rectangle is given in world coordinates rather 

than device coordinates. This means that the current transformation matrix applies. 
This call may be used with retained drawing and metafiles, as well as immediate 
drawing. Aside from these differences, this function follows the same rules as 

40 

GpiBitBltO- 

GpiDrawBitsO 

45 This function is similar to GpiWCBitBltO and calls it to perform its core function. The 

following comprise the differences between the two: 

instead of a source bitmap, the caller specifies image data by supplying pointers 
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25 



directly to bitmap information and image .data. 
In all other respects, this function acts the same as GpiWCBitBlt(). 

GpiCreateBitmapO 

This function creates a bitmap that is logically associated with a particular device. 
The device is the one associated with the presentation space passed in the call. If 
this device is a remote display, the bitmap is marked as server-potential, but not 
downloaded until its first use. 

GpiDeleteBitmapO 

This function deletes a bitmap created with one of the bitmap creation functions. This 
function will cause the bitmap to be removed from the server immediately, if it is 
server-potential and has been downloaded at least once already. If the bitmap is 
a server- permanent bitmap, any call to delete the bitmap executes normally as far 
as PM structures are concerned. But no deletion of the associated server pixmap 
is done. 

GpiLoadBitmapO 



This function acts just like GpiCreateBitmapO, with the following differences; 
instead of obtaining the bitmap image from user supplied data, the bitmap image is 
30 loaded from a resource. 

In all other aspects, this function is the same as GpiCreateBitmapO. 
This f un ction should work unmodified in a remote environment, once it is sanitized. 

35 GpiQueryBitmapBitsQ 

This function retrieves bitmap data from a presentation space which must be 
associated with a bitmap. Since even server- potential bitmaps are stored locally, 

^ this function operates correctly without modification in a remote environment. 

GpiQueryBitmapDimensionO 

This function returns bitmap dimension data that has been previously set with the 
45 GpiSetBitmapDimensionO function.; Bitmap dimension data is not related* to the 

actual size of the bitmap, and in fact, is not utilized by the system at all. This function 
will work without modification in a remote environment. 

50 
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GpiQueryBitmapHandleO ' 

This function returns the bitmap handle that is associated with specific ID that has 
been set with the GpiSetBitmapld() function. It will work without modification in a 

5 

remote environment. 

GpiQueryBitmapParametersO 
w This function returns bitmap size data from a bitmap handle. It will work without 

modification in a remote environment. 



15 



20 



GpiQueryDeviceBitmapFormatsO 

This function returns information about supported bitmap formats for the device 
associated with the passed presentation space. This function must be hooked so 
that only device bitmap formats that are supported by the remote display are 
returned. 

GpiSetBitmapO 

This function associates a bitmap with a presentation space. The presentation space 
25 must be associated with a memory device context. This function must be hooked so 

the bitmap handle is recorded by DPMX. 



30 



GpiSetBitmapBitsO 

This function modifies a bitmap associated with a presentation space. It will worfc 
without modification in a remote environment. 

35 GpiSetBitmapDimensionO 

This function sets bitmap dimension data (not related to the actual size of a bitmap, 
and not utilized by the system at all) that may later be queried with the 
GpiQueryBitmapDimehsionO function. It will work without modification in a remote 
environment. 



40 



GpiSetBitmapldO 

45 This function associates an ID value with a bitmap. Once such an ID has been set, 

the bitmap may be queried by this ID. This function should work without modification 
in a remote environment. 
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WinDrawBitmapO 

This function is similar to GpiWCBitBltO and uses it to perform its core function. The 

following comprise the differences between these two functions: 

destination rectangle is specified in device coordinates, rather than world 

coordinates. 

Foreground color, background color, color inversion, and simple half-toning, but no 
other special operation, may be performed by specifying arguments directly to this 
call. In all other aspects, this function behaves the same as GpiWCBitBltO- 

WinGetSysBitmapO 

This function is similar to GpiLoadBitrnapO. with the following differences: 

the system bitmap to be loaded is specified by a system wide ID; 

the source of the bitmap is specified by naming the desktop window which it will be 

drawn on. 

This allows multiple versions of a bitmap that are each customized for a particular 
type of display. The bitmap is marked as server-permanent; It will remain on the 
. server even after the application that requested it terminates. The downloading only 
occurs the first time the bitmap is requested. 

NEW FUNCTIONS CREATED 

NEW FUNCTION NAME DESCRIPTION 

BrtmapCreateO . Called by XGpiCreateBitmapO 

This function creates a new Virtual' server pixmap that corresponds to a bitmap that 
may POTENTIALLY be displayed. Once created, changes to the associated bitmap 
are 'watched' so that the currency of the server version can be tested. A pixmap is 
not physically transported to the server just because it is created. Only when the 
bitmap is drawn onto a remote window for the first time will it be transported. If 
transported, the bitmap is copied unaltered; i.e. raster -op requests affecting the 
appearance of the bitmap are not utilized in the copy from the host to the server. 
This occurs only when the bitmap is copied from the server -resident pixmap to a 
server- resident window, except in two special cases discussed elsewhere. This 
function will be called by all PM hooked functions that introduce a new bitmap to the 
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system if there is a possibility that the bitmap may be displayed on a remote window. 
It will ensure that the necessary data structures are created for tracking that bitmap. 

BitmapInvalidO Called by XGpiSetBitmapBitsO, XGpiDeleteBitmapO. 

XGpiSetBitmapO, XGpiBitBltO, XGpiWCBitBltO 
This operation causes the server- resident version of the bitmap to be considered 
out of date in relation to the PM version, if it exists. Any further action requiring the 
presence of the bitmap on the server will invoke BitmapTransportO to transport or 
re-transport the bitmap. This function must be called whenever a hooked PM 
function has determined that a bitmap may have changed. This will happen 
whenever any drawing primitive affects a remote presentation space that has a 
server- potential bitmap selected into it. 

.BitmapTransportO Called by XGpiBitBltO, XGpiWCBitBltO 

This operation will transport the bitmap to the server, per -forming all color and 
coordinate transformations along the way. The bitmap is then marked as current. 
Color transformation involves creating a local conversion map. Each PM bitmap color 
(there will be either 2, 16, or 256) will be mapped to the an X pixel value using the 
RGBtoXPixelO function. The bitmap will always be promoted (or demoted) to the 
depth most natural for the server. If the original bitmap has a depth greater than the 
maximum supportable depth on the server, color information will naturally be lost. 

BitmapFindO Called by XGpiWCBitBitO. XGpiBitBltO. XGpiSetBitmapO, 

WinDrawBitmapO, GpiDeleteBitmapO, GpiCreateBitmapO 
This function will return the pointer to the local bitmap tracking structure associated 
with it. The function BitmapCreateO must have been called for the bitmap 
beforehand, or NULL will be returned. 

BitmapDrawO Called by XGpiBitBltO, XGpiWCBitBltO, 

XWinDrawBitmapO, XGpiDrawBitsO 
This function causes a bitmap or a portion of a bitmap to be transferred to a remote 
window. This may involve the update (through the BitmapTransportO function) of the 
bitmap onto the server followed by a server to server copy. Alternatively, if the bitmap 
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BitmapDestroyO 



10 



20 



BitmapProcessQ 



is not of a type that uses a server -resident copy, it is drawn directly to the window. 

Called by XGpiDeleteBitmapO 
This function unassociates a bitmap with any tracking data. If a server- resident 
version of the bitmap exists, current or not, it will be removed from the server. 

Called by XGpiWCBitBltO. XGpiBitBltO, XGpiSetBitmapO. • 
WinDrawBitmapQ. GpiDeleteBitmapO, GpiCreateBitmapO 
This function performs special pre-processing on a bitmap, if necessary, before 
sending i, to the server. Pre-processing always involves translating the original PM 
bitmap to another PM bitmap, which then replaces the original bitmap in further 
processing. Pre-processing conversion will be applied if either 
expansion/contraction is required. In both cases, the appropriate conversions, since 
they cannot be applied at the server, are applied locally to create the replacement 
bitmap. 



25 OTHER FUNCTIONS AFFECTED 
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FUNCTION NAME DESCRIPTION 

GpiPushfj, G P ip °P0. GpiQueryAttrsO, GpiSetAttrsO 

Two-color bitmaps can utilize the current foreground and background colors as 
their color map. These operations affect the current foreground and background 
color. 



RGBtoXPixelQ 



iAddXPSfJ 



This DPMX function is used to translate a bitmap RGB map to X pixel values before 
transporting the bitmap to the server. 

The bitmap reference variable (XPS.pixmap) which is loaded when a bitmap is "sef 
into a presentation space, is initialized to null here. 



so 



.55 



DATA STRUCTURES 

SERVERB^Tn 31 * fraCk ,he stateof a bitma P it's server version is 

dta^S I ! ,heSe iS ° reated h 3 b,0Ck6d ,inked list ,or each bLap that may be poSally 

t^ZJSZZ TIT' b,0Ck9d " nk " St C ° nsi5tS ° f bi,ma P struct ^ ^tries to^TL 
standard linked list format, but are allocated In multiple count groups. 
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STRUCTURES THAT CHANGED 

typedef struct _XPS 
{ 



HPS 


hps; 


/* real presentation space handle on PM side */ 


DPMXWindow 


*pwin; 


/* window this hps is in, if any */ 


long 


ICoordSys; 


/* coordinate system of Presentation Space */ 


GC 


gcLine; 


/* gc used for line attributes on X side */ 


GC 


gcChar; 


/* gc used for character attributes on X side */ 


GC 


gcMarker; 


/* gc used for marker attributes on X side */ 


GC 


gcPattern; 


/* gc used for pattern attributes on X side */ 


GC 


gclmage; 


/* gc used for image- attributes on X side */ 


short 


x; 


/* current x coordinate in the hps-*/ 


short 


y ; 


/* current y coordinate in the hps */ 


LONG 


IGeomWidth; 


/* line width during GpiStrokePath */ 


LONG 


IXPSFIags; 


/* DPMX fiags to keep track of extra stuff */ 


/* Attribute mode and saved attributes we have to keep track of */ 


BOOL 


bAttrSave; 


/* flag to save attributes in LIFO stack */ 


int 


iPMATTRCnt; 


/* count of attributes in attribute stack */ 


PMATTR 


*pPMATTR; 


/* pointer to top of LIFO attribute stack */ 


/* Character 


values we have to keep track of */ 


LONG 


IcidChar; 


/* current Icid for font in use */ 


int 


iCharSets; 


/* count of number of char sets */ 


SETMAP 


*pCharMap; 


/* pointer to top of char set map array */ 


SHORT 


fsSelection; 


/* bold/italic/strikeout/underline flags */ 


USHORT 


usPrecision; 


/* 1 = default, 2 = better, 3 = best */ 


SIZEF 


sizfxChar; 


/* values for w/h of character box */ 


POINTL 


ptIAngle; 


/* point used to determine text angle */ 



EP 0 597 395 A1 



POINTL 

USHORT 

USHORT 

FIXED 

FIXED 



ptIShear; /* defines how pushed over chars are */ 

usDirection; /* |_> r , u ->d, etc. */ 

usTextAlign; I* und.ocumented 7 

fxExtra; /* extra spacing increment for all chars */ 

fxBreakExtra; /* extra spacing increment for break char */ 



/* Marker values we have to keep track of */ 
,nt iMarkerSefs; /* count of number of marker sets */ 

SETMAP 'pMarkerMap; /* pointer to top of marker set map array «/ 
USHORT usMarker; /• current marker symbo| jn marker ^ t/ 
SIZEF sizfxMarker; /* values for w/h of marker box */ 

/* Marker values we have to keep track of */ 
Int * iPatSets; /* count of number of pattern sets */ 

SETMAP "pPatMap; /* pointer to top of pattern set map array */ 
mt iPositionCnt; /* count of number of saved current positions */. 

POINTL *pCurPos; /* pointer to top of current position array */ 

/• Default values we have to keep track of */ 
LINEBUNDLE IbndDefault; 
CHARBUNDLE cbndDefault; 
MARKERBUNDLE mbndDefault; 
AREABUNDLE abndDefault; 
IMAGEBUNDLE abndDefault; 



BOOL 

Pixmap . 

fdef 

char 

XRectangle 

#endif 

} 

XPS; 



ColorDecodeMode; /* FALSE: Indexed off of current index; V 

/* TRUE: Direct RGB triplets */ 
pixmap; /* current pixmap, or NULL if not set */ 

NOT.YET 

cClipRects; /* count of the number of clipping rectangles; */ 
*paxrClipRects; ./* pointer to array of clipping rectangles */ 
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NEW STRUCTURES 

struct SERVERBITMAP 

{ HBITMAP Local; 

Pixmap Server; 

UCHAR Flags; 

}; . . 

#define SERVERBITMAPFLAGcurrent 0x01 // Bitmap is up to date on server 

#define SERVERBITMAPFLAGpermanent 0x02 // Bitmap is to remain stored on 

// the server after termination 



Claims 

1. A system for displaying a program application (3), written for a first operating system, comprising: 

means for allocating a portion of a computer display screen (38). and for providing a user interface, 

based on a second operating system; 

means for enabling commands to said user inter- face to be processed by sa.d application; and 
means for displaying output from said application and said user interface in said port.on of said 

display screen (38). 

2. A system according to claim 1 wherein said means for displaying comprises means for mapping 
commands from said application (3)' to commands which can be interpreted by said second operating 
system. 

3. A system according to claim 2 wherein said means for mapping comprises means for creating function 
in said second operating system to accommodate function present in said application (3) 

4. A system according to claim any preceding claims wherein said enabling means comprises: 

means for interpreting commands directed to said application (3); and 

means for translating said commands into a form recognizable by said application (3). 

5 A system according to claims 3 or 4 wherein said means for creating function comprises: 

means for comparing the application function with function provided by said second operating 

system; .. .. 

means for determining the function within said second operating system related to said application 

function; and ,.■<»• 
means for using the function in said second operating system to simulate the application function. 

6. A method of displaying a program application (3), written for a first operating system, comprising the 

steps of: . . . . 

allocating a portion of a computer display screen (38), and for providing said user interface based 

on a second operating system; 

enabling commands to said user interface to be processed by said application; and 

displaying output from said application (3) and said user interface in said portion of said display 

screen. 

7. A method according to claim 6 wherein said step of displaying comprises the step of mapping 
commands from said application (3) to commands which can be interpreted by said second operating 
system. 

8. A method according to claim 7 wherein said step of mapping comprises creating function in said 
second operating to accommodate function present in said application (3). 
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9. A method according to any claim from 6 to 8 wherein said step of enabling comprises the steps of: 

interpreting commands directed to said application; and 

translating said commands into a form recognizable by said application. 

10. A method according to claim 8 or 9 wherein said step of creating function comprises the steps of: 

comparing the application function with function provided by said second operating system; 
determining the function within said second operating system related to said application function- 
and . 

using the function in said second operating system to simulate the application function. 



EP 0 597 395 A1 




EP 0 597 395 A1 



APP 



PM Gp>» Win API 



MAPPING TO X 



XLIB 



OS/2 



TCP/IP 



AIX 



■101 



X11 
SERVER 


^-103 


WINDOW 
MANAGER 






FIG. 2 



EP 0 597 395 A1 



15Z 121 . .119 




•109 



X WINDOW 
XAPP. 



113 



L 



.121 



X WINDOW 
PM APP. 



117 



FIG. 3 



107 




111 



■109 



113 



X WINDOW 
XAPP. 



PM WINDOW 
PM APP. 



117 



FIG. 4 



EP 0 597 395 A1 



STEP 1 



STEP 2 



STEP 3 



START REMOTE APP (PM) 






CREATE WINDOW I 






MAP BETWEE 
FOR WINDOl 


ENPMANDX 
W HANDLES 




NO 



STEP 5 



STEP 6 



STEP 7 





YES 

r 


TRANSLATE COORDINATES | 




> 


MAKE CALL TO X LIB | 







DRAW LINE INTO WINDOW 



T 
© 



FIG. 5A 



EP 0 597 395 A1 



STEP 8 




STEP 9 



STEP 10 



STEP 11 



TRANSLATE TEXT CHARAC. 



MAP PM FONT TO X FONT 



DISPLAY TEXT IN WIN. 



T 
© 



STEP 12 




STEP 13 



1 


YES 


PM GIVES COORDINATES OF END POINTS 







© 



FIG. 5B 



EP 0 597 395 A1 



STEP 14 



STEP 15 




STEP 22 



MAKE CALL TO X LIB 

~~T — ~ 



DISPLAY OUTPUT 



STEP 23 



STEP 24 



STEP 25 



STEP 18 



X RETURNS IDENTIFIER 
(KEY NO. OR MOUSE 
POSITION/CLICK) 



STEP 19 



TRANSLATE TO 
CORRESPONDING LETTER 
BASED ON PREDETERMINED 
CONDfflONS 



STEP 20 



SENDTOPMAPP 



FIG. 5C 



STEP 21 




J 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 93 11 7959 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 

to d aim 



CLASSIFICATION OF THE 
APPLICATION (IntXLS) 



COMPUTER DESIGN. 

vol. 31, no. 8 , August 1992 , LITTLETON, 

MASSACHUSETTS US 

pages 50 - 54 XP307564 

WILLIAMS 'Tools help move applications 

between different GUIs 1 

* the whole document * 

IBM TECHNICAL DISCLOSURE BULLETIN. 

vol. 35, no. 2 , July 1992 , NEW YORK US 

pages 323 - 332 XP313316 

'OS/2 Presentation Manager clipboard 

support for a windowed 5250 emulator 1 

* the whole document * 

IBM TECHNICAL DISCLOSURE BULLETIN. 

vol. 35, no. 6 , November 1992 , NEW YORK 

US 

pages 357 - 360 XP314181 

'Window class library with command table 

dispatching* 

* the whole document * 



1-10 



G06F9/44 



1-10 



1-10 



TECHNICAL FIELDS 
SEARCHED (lntCLS) 



G06F 



The present search report has been drawn up for all daims 



Place mt mvc* 

THE HAGUE 



Dale of GDa^Mlaa of tfca tear* 

17 February 1994 



Brandt, J 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant If taken alone 

Y : particularly relevant If combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the Invention 
E : earlier patent document, but published on, or 

after the flllag date 
D : document dted In the application 
L : document dted for other reasons 

a : member of the same patent family! corresponding 
document 



